@bors try @rust-timer queue

☀️ Try build successful (CI)
Build commit: 865ecdf (865ecdfbe4eabbe37c87a8ca94acf068e7bf5bd2)
Base parent: c397dae (c397dae808f70caebab1fc4e11b3edf7e59f58c7)

Finished benchmarking commit (865ecdf): comparison URL.

Overall result: no relevant changes - no action needed

Benchmarking means the PR may be perf-sensitive. Consider adding rollup=never if this change is not fit for rolling up.

@rustbot label: -S-waiting-on-perf -perf-regression

Instruction count

This perf run didn't have relevant results for this metric.

Max RSS (memory usage)

This perf run didn't have relevant results for this metric.

Cycles

Binary size

This perf run didn't have relevant results for this metric.

Bootstrap: 485.944s -> 487.045s (0.23%)
Artifact size: 393.37 MiB -> 393.80 MiB (0.11%)

(I'll continue reviewing tomorrow.)

I don't remember what we decided regarding cases like this

// --extern foo::bar=PATH

mod foo {}

let x = foo::bar::something;

Should the module mod foo link to the open module foo from the extern option?
Or there should be an error "there's no bar in foo".

Suppose we do link to the open module from the item module.
Then supposedly we should follow the link in cases like

// --extern foo::bar=PATH

mod foo {
  // foo is the current module, so we go through all the 3 scopes in it including the open mod link
  // this certainly doesn't look like it should work
  let x = bar::something;                                      
}

mod other {
  use crate::foo as renamed;
  // we go through all the 3 scopes in the module to which `renamed` refers, including the open mod link
  // this also doesn't look like it should work
  let x = renamed::bar;
}

The problem is that the similar concerns exist if we insert the links only into "crate root" modules, like this PR does.

// --extern foo::bar=PATH

extern crate foo;

mod other {
  use crate::foo as renamed;
  // we go through all the 3 scopes in the module to which `renamed` refers, including the open mod link
  // this also doesn't look like it should work
  let x = renamed::bar;
}

At least the "current module" problem is harder to trigger (but still possible!)

// --extern foo::bar=PATH

extern crate self as foo;

// foo is the current module, so we go through all the 3 scopes in it including the open mod link
// this certainly doesn't look like it should work
let x = bar::something;

It's quite clear that the open mod links only need to be considered in the ScopeSet::Module mode.

Also, if the links only work in ScopeSet::Module mode, then we'll be able to backward compatibly extend the set of modules into which the links are planted (e.g. from root modules to mod foo items), so we can start with just root modules.

The cases in which the links are followed still need to be restricted somehow, to avoid the cases from #158724 (comment).
(Abandoning the model with links from modules entirely would require even more fundamental hacks to name resolution.)

The PR misses all the test cases that demonstrate why this feature is tricky to implement.
For example:

• glob declaration in a module emerges from a macro, after the open mod link declaration is already available
• non-glob declaration in a module emerges from a macro, after the open mod link declaration is already available
• extern crate declaration emerges from a macro and adds a link to a module in which some glob or non-glob declaration with the same name already exists.
• extern crate declaration emerges from a macro and adds a link to a module in which nothing with the same name exists

This needs design, and I need maybe one full day to try implementing it myself and think about the details, but I don't have much time for this, unfortunately.

@TaKO8Ki
Could you add the test cases from #158724 (comment) and #158724 (comment) for now?
Also need a test with --extern introducing open module having the name of one of the built-in crates, e.g. std.
@rustbot author